Several programming languages allow users to access object member using both a primary and secondary object model. For example, both E4X and Visual Basic 9.0 provide users the ability to access XML objects (secondary objects) using the same member access notation as ordinary object (primary objects) accessing. In these cases, the compiler must reinterpret the accesses in the primary object model into an access in the secondary object model.
However, problems can arise where there is ambiguity as to which model, i.e., the primary or secondary, the user may wish to access the particular object. Currently, compilers assume that an access is being made to the secondary object model unless there is an existing member in the primary object access model. For example, consider the piece of XML code 100 illustrated in FIG. 1. This piece of code may correspond to an XML object called “doc” for example. If the user tries to access the element Name by referencing “doc.Name”, the compiler may be unsure if the user wishes to get the text associated with the Name element according to the secondary object model, or if the user wishes to access the member Name according to the primary object model. Similarly, if the user wishes to retrieve the first element corresponding to “doc.Add(0)”, the compiler will be unsure if the user wants to add “0” to the doc element according to the primary object model, or retrieve the first element called Add according to the secondary object model.
In yet another example, a user may wish to access the element foo-bar of the XML document by typing “doc.foo-bar”. In many programming languages this type of syntax is reserved and cannot be used for the primary object access, but will instead be interpreted by the compiler as the value “doc.foo”—the value of bar, for example. This is not desirable and may cause confusion when, as in this example, foo-bar is an acceptable name for an element of the secondary object model.
Prior solutions to this problem include explicit accesses through the primary object model into the secondary object using expressions such as doc.element(“Add”), for example. However, these types of accesses are clumsy and it may be desirable to incorporate the notation of the underlying secondary object model into the syntax of the compiler or programming environment.